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This  final  technical  report  presents  a comprehensive  summary  of  work 
performed  by  Martin  Marietta  Aerospace  in  the  development  of  the  IPAC 
Requirements  Interpretation  System  (IRIS).  This  work  is  significant 
because  it  provides  an  automated  capability  for  interactive  information 
retrieval  to  aid  PACOM  Watch  Analysts  in  rapidly  focusing  on  the  best 
data  and  collection  resources  in  response  to  their  immediate  information 
needs.  The  system  supports  the  analyst  by  allowing  him  to  specify  a 
structured  hierarchy  of  information  subjects  at  a display  terminal. 

Following  this,  the  system  computes  the  pertinence  of  data  and  collection 
sources  stored  in  its  data  base  to  these  information  subjects,  assigns 
rating  factors,  and  displays  these  to  the  analyst.  This  informs  the  analyst 
of  further  source  data  access  or  collection  system  tasking,  done  outside 
the  IRIS  system,  that  will  fulfill  his  information  needs. 

The  objective  of  the  effort  was  to  implement  a prototype  system  of  hardware 
and  software,  deliver  it  to  the  Intelligence  Center,  Pacific,  provide  user 
training,  and  allow  the  user  to  exercise  and  evaluate  the  system  with  a 
view  toward  eventual  augmentation  of  the  data  base  to  cover  more  data 
sources  and  collectors.  The  final  report  describes  this  prototype  system 
and  contains  recommendations  for  future  improvement. 
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SECTION  I 
INTRODUCTION 


The  IPAC  Requirements  Interpretation  System  (IRIS)  is  an  all-source  intelli- 
gence data  support  system.  It  was  developed  to  accomplish  two  objectives: 
o Increase  the  timeliness  and  completeness  of  the  Indications  and 
Warning  (I&W)  function  of  PACOM/IPAC  by  providing  the  Watch  access 
to  sensor  and  source  data  related  to  the  current  situation  and 
thereby  enhance  his  ability  to  make  judgements  on  the  feasibility 
of  special  data  processing  or  ad  hoc  collections  and,  in  turn,  aug- 
ment his  ability  to  initiate  requests  for  data  through  the  appro- 
priate sensor  owner /operator . 

o Assist  analysts  in  the  determination  of  the  full  potential  of  infor- 
mation system  assets  (national,  unified,  specified  or  component  com- 
mand) which  may  be  applicable  to  his  problem,  and  provide  aid  to  the 
analysts  in  formatting  of  proper  requirements. 


IRIS  has  been  implemented  on  a dedicated  PDP-11 /45  mini-computer  in  which 
application  software  and  required  data  bases  are  resident.  The  system  is 
bi-modal  to  accommodate  both  experienced  and  novice  users.  A structured 
event  sequence  mode  leads  the  novice  user,  with  explanatory  tutorials  from 
his  specification  of  an  information  requirement,  or  query,  through  the  iden- 
tification of  information  system  outputs  to  the  generation  of  tasking  mes- 
sages. A relatively  unstructured  option  mode  permits  the  experienced  user 
to  select  only  those  analysis  procedures  and  data  files  for  review  that  are 
germane  to  the  solution  of  his  problem. 


The  IRIS  data  base  consists  of: 

o Files  which  the  IRIS  application  software  uses  to  enable  a transition 
from  user  queries  to  the  identification  of  information  system  outputs. 

o Files  in  which  the  information  system  characteristics  and  capa- 
bilities are  detailed. 

o Files  which  contain  data  required  to  support  the  user's  validation 
of  information  systems'  outputs  selected  for  access. 
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IRIS/IOC  (Initial  Operational  Capability)  requires  the  user  to  actively 
participate  in  the  review  of  information  system  output  data,  and  in  the 
analysis  of  information  system  operation.  He  also  makes  decisions  relative 
to  the  initiation  of  actions  leading  to  the  acquisition  of  these  outputs. 

This  apparent  excessive  user  interaction  in  the  initial  operations  of  IRIS, 
is  supported  by  two  arguments: 

o The  IRIS  user  must  develop  confidence  in  the  technical  integrity  of 
IRIS  data  and  analyses.  This  can  be  accomplished  by  his  review  of 
information  system-related  data  which  would  be  the  basis  of  automatic 
data  processing  (ADP)  selection  procedures  in  a more  mature  IRIS, 
o Only  a day-to-day  user  can  identify  those  selection  and  decision 

criteria  which  should  be  automated.  Experience  suggests  that  judge- 
ments influenced  by  IRIS  data  characterized  by  subtleties  in  meaning 
which  cannot  be  concisely  reduced  to  words  or  numbers,  should  remain 
within  the  purview  of  the  user. 

The  evolution  into  IRIS/FOC  (Final  Operational  Capability)  with  more  com- 
pletely automated  operations,  will  be  determined  by  users'  needs  rather  than 
an  a priori  operations  analysis. 
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SECTION  II 
PROBLEM  STATEMENT 

The  IPAC  Watch,  among  other  responsibilities,  is  required  to  review  message 
traffic  with  the  object  of: 

o Identifying  possible  anomalies  which  cannot  be  explained  by  avail- 
able resources  or  by  other  routine  data,  and 
o Taking  the  action  required  to  initiate  the  acquisition  of  that  in- 
formation which  will  explain  or  clarify  the  identified  anomalies. 

The  volume  of  such  traffic  having  uncertainties  increases  prior  to  and 
during  crises.  The  capability  of  the  Watch  personnel  to  specify  new  infor- 
mation requirements  in  a timely  manner  may  not  be  adequate  for  the  proper 
support  of  J-2.  Furthermore,  the  large  array  of  products  from  all  poten- 
tially applicable  collection  disciplines  is  such  that  solutions  to  new  in- 
formation requirements  identified  by  a given  Watch  team  may  not  be  the  best 
solutions  to  the  current  problem. 

These  two  difficulties  have  a common  problem.  Watch  personnel  do  not  have 
readily  available  data  which  will: 

o Permit  a timely  transition  from  an  information  requirement  to  the 
identification  of  information  svstem  outputs,  or  products,  that 
could  satisfy  the  requirement  (without  regard  for  any  specific 
collection  discipline  bias); 

o Provide  enough  data  about  the  output  and  the  producing  system  so 

that  there  is  a rational  basis  for  a decision  to  initiate  the  acqui- 
sition of  specific  information;  and 
o Encompass  the  variety  of  potential  information  sources,  for  both 
military  and  non-military  situations,  necessary  to  support  all 
types  of  information  requirements. 


8 


a?*  • * 


SECTION  III 


i 


SOLUTION  CONCEPT 


The  elements  of  the  stated  problem  suggested  a sequenced  approach  to  accom- 
modate the  solution  of  information  requirements,  since  such  queries  could  not 
be  specified  a priori  in  the  IRIS  design  criteria.  This  solution  sequence 
was  seen  to  consist  of  four  discrete  steps: 

o Transition  from  a stated  query  to  the  identification  of  specific 
information  system  outputs  which  could  partially  or  totally  satisfy 
the  requirement. 

o Review  or  analysis  of  relevant  information  system  technical  and 
operational  characteristics  to  verify  which  of  the  identified  out- 
puts constitute  potentially  reasonable  solutions, 
o Selection  of  one  or  more  of  the  solutions  derived  in  the  first  two 
steps  and  initiation  of  the  acquisition  of  the  identified  output(s) . 
o Development  and  maintenance  of  a record  of  the  problem;  i.e.,  the 
uncertainty  that  stimulated  the  use  of  IRIS  and  the  consequent 
actions  under  IRIS  direction. 

Of  these,  it  was  apparent  that  IRIS  could  actively  support  the  first,  second, 
and  fourth  steps.  The  third  step  is  strongly  dependent  on  judgement  which 
could  only  be  properly  implemented  in  an  ADP  system  on  an  evolutionary  basis. 
However,  IRIS  could  provide  limited  support  to  the  second  part  of  the  third 
step.  The  four  step  conceptual  approach  was  developed  as  described  in 
Subsections  A,  B,  C and  D that  follow. 

A.  QUERY  SOLUTION  IDENTIFICATION 

Potentially  the  first  step,  (requirement  interpretation  and  identification 
of  applicable  information  system  outputs)  was  partitioned  into  two  tasks: 
o Representation  of  a substantive  query  to  IRIS  in  a manner  that 

would  allow  software  to  operate  on  it  and  identify  candidate  solu- 
tions . 

o Development  of  a working  data  base  in  IRIS  containing  potential  dis- 
playable  solutions  to  substantive  queries.  Such  a data  base  would 
have  to  grow  incrementally.  An  IOC/IRIS  could  not  include  a data 
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base  that  would  be  permanently  valid  since  newer  information  systems 
are  continually  emerging  and  outputs  from  existing  systems  are  some- 
times replaced  by  other  outputs. 

1.  Query  Representation 

The  approach  to  the  first  of  these  tasks  was  based  on  the  general  premise 
that  every  query  is  characterized  by  a subject  (about  which  something  is 
desired  to  be  known)  and  a discrete  set  of  information  needs  (what  is  re- 
quired to  be  known  about  the  subject).  The  elements  of  a given  query,  cor- 
related with  an  IRIS  subject  catalog  element  and  one  or  more  elements  in  an 
IRIS  information  need  file  would  permit  the  translation  of  the  presented 
query  into  termr  compatible  with  IRIS  software. 

2.  Data  Base  Support  of  Candidate  Solutions 

The  approach  to  the  second  of  these  tasks  was  strongly  influenced  by  the 
need  to  combine  and  screen  information  concerning  intelligence  subjects, 
potential  collection  disciplines,  and  information  needs  of  the  query.  The 
merging  and  subsequent  screening  process  to  determine  and  present  candidate 
solutions  to  information  requirements  (queries)  is  referred  to  as  the  Re- 
quirement Interpretation  Matrix  (RIM)  analysis.  This  concept  involves  the 
development  of  two  separate  analyst-generated  data  files,  with  a strong  re- 
quirement to  include  more  than  just  a token  set  of  data  that  would  be  suf- 
ficient to  demonstrate  IRIS  methodology.  These  two  data  files  constitute: 
o The  determination,  for  each  element  of  the  IRIS  Subject  Catalog 
(SUCAT) , of  the  information  needs  which  could  be  satisfied  by  any 
collection  discipline  that  is  compatible  with  observables  of  the 
subject.  This  file  was  assigned  the  acronym  SUMAT  (for  Subject 
Matrix) . 

o The  determination,  for  each  IRIS  information  system  output,  of  the 
needs  which  could  be  satisfied,  and  how  well,  by  the  output.  This 
file  was  assigned  the  acronym  SYSMAT  (for  Information  System  Output 
Analysis  Matrix). 

The  RIM  analysis  approach,  depicted  in  Figure  1,  only  required  about  1040 
subject  analyses  (multiplied  by  an  average  of  nine  associated  collection 
disciplines)  plus  about  140  information  system  analyses.  If  this  approach 
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Figure  1 Requirements  Interpretation  Matrix  (RIM)  Analysis 
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were  not  employed,  alternate  approaches  would  result  in  a data  array  requir- 
ing 1040  x 9 x 140  = 1,310,400  separate  analyses  to  combine  the  separate 
SUMAT  and  SYSMAT  by  manual  analysis  exercise. 

The  approach  also  was  compatible  with  the  implicit  evolutionary  growth  of 
either  the  subject  catalog  or  the  set  of  information  system  outputs. 

B.  CANDIDATE  SOLUTION  REVIEW 

The  second  step,  (user  screening  of  information  systems  or  information  system 
outputs  based  on  technical  or  operating  constraints)  was  partitioned  into 
three  tasks: 

o An  efficient  assembly  of  information  system  output  and  information 
system  characteristics,  the  review  of  which  could  confirm  (or  negate) 
the  IRIS  identification  of  the  output  as  a candidate  solution, 
o The  assembly  of  query  subject  signature  data,  which  would  enable  veri- 
fication of  technical  compatibility  of  the  information  system  with 
the  query  subject. 

o The  derivation  of  simple  measures  of  information  acquisition  oppor- 
tunity (locational  and  timeliness  aspects  of  the  query  vis  a vis  what 
the  system  can  provide). 

1.  Information  System  Output  Data 

The  approach  to  the  first  of  these  tasks  involved  the  categorization  of  var- 
ious information  system  and  output  characteristics  that  would  directly  sup- 
port the  subsequent  two  tasks,  and  at  the  same  time  provide  a core  reference 
that  could  be  easily  modified  or  enlarged.  The  categorization  that  was  found 
to  be  relevant  to  the  IRIS  user  needs  was: 

o Executive  Summary:  A condensation  of  the  various  information  system 

and  output  characteristics  which  would  provide  a rapid  overview  to 
the  user. 

o Output  Content:  The  information  contained  in  the  identified  output 

(this  would  be  reflected  in  the  SYSMAT  described  above), 
o Output  Quality:  The  accuracy,  timeliness  (after  raw  data  acquisi- 

tion) and  completeness  aspects  of  the  output  (these  would  form  the 
bases  for  the  SYSMAT  figures  of  merit,  above). 
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o Output  Access  Methods:  Accessing  protocol  and  the  identification  of 

required  standard  message  forms  to  be  used  in  the  event  the  acquisi- 
tion of  this  output  is  to  be  initiated.  This  would  support  accom- 
plishment of  the  third  step  discussed  in  Subsection  B below, 
o System  Technical  Characteristics:  Those  technical  descriptors  of  the 

information  system  that  would  support  the  signature  compatibility 
analysis  related  to  the  query  signature,  or  that  may  be  required  in 
an  acquisition  opportunity  evaluation, 
o System  Operational  Characteristics:  General  operational  constraints, 

the  knowledge  of  which  could  facilitate  a decision  to  pursue  a more 
detailed  acquisition  opportunity  evaluation. 

These  six  categories  represented  an  acceptable  top  level  structure.  However, 
it  was  recognized  that  the  data  for  different  kinds  of  information  system 
outputs  would  differ  significantly  and  that  there  should  be  provisions  for 
an  informal  structure  of  the  data  presentation  which  permits  easy  modifica- 
tions or  additions  to  the  data. 

2.  Subject  Signature  Data 

The  second  task  concept  identified  the  need  for  arrays  of  data  that  would  re- 
late query  with  types  of  signature  or  phenomenologies  to  which  a sensor  can 
react.  These  arrays  would  be  associated  with  each  of  the  collection  disci- 
plines represented  by  the  identified  collection  system  output.  Five  subject 
signature  files  were  identified: 
o ELINT  (Radar  emissions) 
o PHOTINT  (Resolution  requirements) 
o RADINT  (Radar  cross-sections) 
o ACINT  (Acoustic  emissions) 
o IRINT  (Infrared  emissions) 

These  data  would  be  so  derived  and  assembled  that  the  IRIS  user  could  readily 
verify  compatibility  between  the  applicable  signature  of  the  subject  of  his 
current  query  and  any  technical  attribute  of  the  information  system  that 
would  be  related  to  the  acquisition  of  the  identified  output.  Further,  the 
assembly  of  such  data  should  not  be  so  transparent  to  the  IRIS  user  that  he 
is  unable,  drawing  on  his  specific  intelligence  background,  to  critically 
assess  the  accuracy  and  completeness  of  these  signature  data. 
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3.  Acquisition  Opportunity  Analysis 


The  third  task  was  identified  as  requisite  to  an  IRIS  user's  ability  to 
assess  the  practicality  of  accessing  the  identified  output,  when  the  timeli- 
ness and  geographic  specifics  of  his  query  are  considered.  However,  it  was 
also  recognized  that  an  information  acquisition  opportunity  analysis  must  be 
kept  simple  enough  so  that  it  would  remain  a tool  to  facilitate  the  overall 
IRIS  analysis  flow  and  not  become  a central  analysis  as  in  a collection 
management  system.  This  criterion  dictated  the  need  for  simple  information 
system  performance  measures  and  simple  inputs  by  the  IRIS  user.  For  example, 
in  the  case  of  an  airborne  ELINT  system,  the  feasibility  of  its  employment 
would  be  measured  by  total  possible  collection  time,  and  the  user  would  be 
required  to  input  only  the  location  of  a point  target.  Sophistications  such 
as  terrain  or  weather  effects,  EMCON  or  platform  availability  would  be  typi- 
cal omissions  in  an  analysis  only  having  the  objective  of  determining  rela- 
tive feasibility.  It  was  recognized  that  IRIS  may  never  be  capable  of  main- 
taining current  information  system  status  (e.g.,  health,  readiness,  sensor 
configurations  or  modes,  and  weather  effects).  The  acquisition  of  such  data 
from  authoritative  sources  would  involve  delays  that  would  be  inconsistent 
with  the  objective  responsiveness  of  IRIS.  Hence,  this  type  of  analysis 
should  be  limited  to  only  that  which  is  required  to  achieve  relative  measures 
o f per f ormanc e . 

C.  IDENTIFIED  OUTPUT  ACQUISITION  REQUESTS 

With  reference  to  the  sequenced  approach  discussed  at  the  begining  of  this 
section,  the  part  of  the  third  step  that  IRIS  could  support  is  related  to  the 
development  of  specifically  applicable  acquisition  requests  and  messages. 

This  development  is  consistent  with  the  protocol  required  by  the  information 
system.  This  was  recognized  as  a convenient  way  in  which  the  IRIS  user, 
having  made  the  decision  to  access  one  or  more  of  the  identified  outputs, 
could  draft  a formalization  of  his  request.  Inclusion  of  the  directed  and 
information  addresses  and  use  of  recognized  wording  in  such  a message  draft 
would  facilitate  the  actual  processing.  The  concept  to  be  developed  in  IRIS 
would  involve  assembly  of  the  appropriate  message  forms,  executed  for  a 
sample  message,  and  with  the  applicable  outputs  identified.  These  message 
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forms  would  be  stored  in  dedicated  files  and  would  be  dis- layed  only  when 
the  user  had  made  a conscious  decision  to  request  a specific  information 
system  output. 

D.  RECORD  KEEPING 

The  fourth  and  last  step  in  the  sequenced  approach  was  recognized  as  a nec- 
essary IRIS  activity  for  two  reasons: 

o The  quantity  and  variety  of  data  the  user  could  be  expected  to  en- 
counter, particularly  if  several  information  system  outputs  were 
being  evaluated,  dictate  a need  to  save  pertinent  facts  germane  to 
the  output  selection  decision. 

o The  documentation  of  the  analysis  process  (and  consequent  results) 
that  the  user  would  carry  out  from  the  statement  of  the  information 
requirement  to  the  selection  and  requesting  of  one  or  more  outputs, 
would  have  historical  value  in  subsequent  review  of  Watch  activities. 

These  IRIS  transaction  results  would  in  fact  be  complementary  to  the 
regular  Watch  log. 

Accordingly,  it  was  determined  that  there  be  some  type  of  "scratch  pad" 
capability  within  IRIS  that  should  exist  as  long  as  a specific  information 
requirement  was  being  worked  and  that  there  also  be  a permanent  log,  created 
from  a subset  of  the  scratch  pad  data  and  permanently  retained. 
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IRIS  DEVELOPMENT  REQUIREMENTS 

IRIS  development  requirements  were  established  by  the  integrated 
definition  and  refinement  of  software,  data  base  and  analysis  requirements. 
IPAC  specified  the  original  computer  hardware  and  top-level  requirements. 
Detailed  requirements  were  derived  from  analyses  conducted  during  method 
development,  data  file  assembly  and  preliminary  IRIS  demonstrations.  This 
section  summarizes  these  development  requirements. 


A.  SOFTWARE  REQUIREMENTS 

The  IRIS  software  requirements  were  defined  and  established  on  the  basis 
of  the  computer  system,  development  plan,  and  analysis  derived  requirements. 
The  computer  hardware,  software  system  and  programming  language  require- 
ments used  in  the  development  of  IRIS  are  summarized  in  Table  1.  An 
extraction  of  the  top-level  operational  requirements  stated  by  IPAC  are 
presented  in  Table  2.  These  two  sets  of  requirements  represent  the  IRIS 
baseline  at  the  time  of  contract  go-ahead.  A detailed  list  of  data  base 
structure,  man/machine  interface,  and  software  operation  requirements 
were  then  derived  from  in  depth  design  analyses.  These  derived  requirements 
are  summarized  in  Table  3. 

B.  DATA  BASE  REQUIREMENTS 

The  data  base  requirements  were  established  through  development  of  an 
operational  method  for  IRIS  and  the  subsequent  definition  of  necessary 
source  data  to  support  the  process.  Table  4 presents  a tabulation  of  the 
data  base  files  determined  to  be  necessary  to  support  the  IRIS  process. 

This  table  also  includes  a brief  description  of  the  functional  importance 
and  IRIS  use  of  each  file.  Specific  requirements  of  the  individual  data 
base  files  are  presented  in  Table  5.  Combining  the  requirements  of  this 
table  with  the  software  structural  requirements  (see  Table  3)  established 
the  major  development  requirements  for  IRIS. 
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TABLE  1 COMPUTER  SYSTEM  REQUIREMENTS 


o The  software  shall  be  implemented  for  operation  on  a DEC  PDP  11/45 
mini -computer  with  64K  words  of  core  storage. 

o The  mass  storage  subsystem  shall  be  a RP-04  disk  and  two  RK-05  disks. 

o The  input/output  (I/O)  functions  shall  be  accomplished  with  either  a 
LA-36  DECwriter  or  a Univac  1652  Dual  Display  Scope. 

o The  computer  software  system  shall  be  the  RSX-11D,  Version  6B. 

o The  programming  language  shall  be  Fortran  IV  Plus.  The  use  of  assembly 
language  to  circumvent  excessive  software  complications  must  be  justified 
to  IPAC  prior  to  usage. 

TABLE  2 IPAC  REQUIREMENTS 

o IRIS  shall  be  simple  to  operate  by  any  Watch  or  I&W  analyst  personnel, 
few  of  whom  shall  be  expected  to  be  proficient  in  operating  an  inter- 
active computer  system. 

o IRIS  shall  lead  the  inexperienced  user  through  the  accomplishment  of 
specific  screening,  analytic  and  data  review  functions. 

o IRIS  shall  be  capable  of  facilitating  data  base  growth  and  of  facile 
updating. 

o IRIS  shall  be  a stand-alone  system  with  the  data  base  a sufficient 
source  for  the  user  to  obtain  a solution  satisfying  an  information 
requirement . 

o IRIS  shall  produce  rapid  solutions,  for  the  experienced  user,  to  the 
posed  information  requirements.  Inherently  long  analyses  or  reviews 
shall  be  capable  of  being  omitted  by  the  user. 

o IRIS  shall  provide  the  capability  to  accumulate  the  results  of  its  use 
for  permanent  retention;  i.e.,  an  IRIS  Log. 
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TABLE  3 DERIVED  REQUIREMENTS 


Data  Base  File  Structure  Requirements 


o IRIS  software  shall  be  capable  of  working  with  three  distinct  file  types: 

1)  Structured  indentured-textural  information, 

2)  Structured  data  formats,  and 

3)  Free-form  textual  data  with  asterisk  divisions. 

o The  format  shall  be  established  for  each  structured  file  that  is  used 
to  store  IRIS  computational  and  control  data. 

o Structured  files  shall  be  re-organized  by  IRIS  file  build  software  for 
ease  of  access  during  run-time  processing. 

o The  SUCAT  shall  be  a structured  indentured-textual  file  that  provides 
retention  for  an  intelligence  subject  catalog  with  increasing  identity 
at  each  succeeding  level. 

o The  SUMAT,  SYSMAT,  INC  and  TRACK  files  shall  be  structured  data  files 
that  provide  retention  of  IRIS  computational  and  control  data. 

o Free-form  textual  files  shall  require  only  superficial  format  definition, 
limited  to  the  top  level  structure. 

o The  ASCAP,  MSGFORM  and  INC  definition  files  shall  be  free-form  textual 
files  that  provide  retention  of  display  data  for  user  review  purposes. 
These  files  shall  not  be  formulated  for  retrieval  of  specific  data 
elements  by  automatic  processing  methods. 

o The  SYSCAT  and  the  INTSIG  files  shall  contain  a combination  of  structured 
data  and  free-form  textual  data,  and  shall  provide  for  retention  of  both 
correlation/directory  data  and  display  data  within  the  same  file. 

Man/Machine  Interface  Requirements 

o IRIS  software  shall  exploit,  as  much  as  possible,  the  dual  presentation 
capability  of  the  Univac  1652  Display  Scope.  Simultaneous  display  of 
two  independent  sets  of  IRIS  file  data  will  enable  rapid  and  accurate 
manual  assessment  by  the  user  and  thus  preclude  the  need  for  complex 
software  comparison. 

o User  commands  and  terminal  controls  shall  be  minimized  and  simple  to 
execute . 

o IRIS  software  shall  provide  the  user  the  capability  of  selecting  either 
a predefined  sequence  mode  of  operation  or  an  optimal  mode  of  operation. 


(Continued) 
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TABLE  3 DERIVED  REQUIREMENTS  (Continued) 


o The  IRIS  subjects  and  information  needs  shall  be  displayed  for  user 
specification  of  elements  most  closely  representing  the  information 
requirement  of  the  user. 

o Software  candidate  solutions  from  the  RIM  screening  process  shall  be 
displayed  for  user  review  and  subsequent  selection  of  ASCAP  files  to  be 
reviewed. 

o User  designated  ASCAP  files  shall  be  displayed  and  reviewable  by  means 
of  simple  paging  and  scrolling  commands. 

o Applicable  INTSIG  information  shall  be  displayed  for  the  subject  of 
the  information  requirement. 

o Applicable  COLOP  user  instructions  shall  be  displayed  for  the  information 
system  being  assessed. 

o User  designated  MSGFORM  files  shall  be  displayed,  an  additional  conmand 
shall  transfer  this  display  to  hardcopy  output. 

o User  designated,  interim  analysis  data  shall  be  transferred  to  a Scratch 
file  (user  working  file)  for  later  review  of  analysis  progress. 

o The  user  shall  be  capable  of  reviewing  the  contents  of  the  Scratch  file 
(user  working  file)  for  later  review  of  analysis  progress. 

o The  user  shall  be  capable  of  reviewing  the  contents  of  the  Scratch  file 
and  the  IRIS  Log  at  any  time  during  the  IRIS  process. 

o Clear,  user-oriented  tutorials  shall  be  displayed  to  the  user  to  present 
instructions  regarding  current  operational  alternatives. 

o User  recovery  procedures  shall  be  displayed  as  an  integral  part  of  the 
system  error  diagnostics. 

o Because  the  activation  of  the  Univac  1652  Display  Scope  relative  to  the 
IRIS  software  development  schedule  is  uncertain,  software  validation 
tests  shall  be  conducted  using  a teletype-compatible  terminal. 

Software  Operation  Requirements 

o IRIS  software  shall  be  designed,  implemented  and  validated  using  unclass- 
ified data.  The  various  classified  data  files  shall  be  merged  into 
IRIS  on  the  IPAC  computer. 

o The  user  selected  subject  and  information  need  categories  (INCs)  shall 
be  used  to  automatically  control  the  various  IRIS  analysis  processes. 
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TABLE  3 DERIVED  REQUIREMENTS  (Concluded) 


o A RIM  screening  process  shall  be  implemented  for  the  identified  subject 
and  INCs,  using  the  stored  SUMAT  and  SYSMAT  data  files. 

o The  COLOP  subroutines  shall  provide  quantitative  data  acquisition 
opportunity  assessments  for  the  selected  information  system. 

o Recording  of  selected  data  file  elements  in  the  permanent  IRIS  Log  shall 
be  accomplished  without  recourse  to  user  interaction. 

o An  optional  IRIS  restart  capability  shall  be  provided  by  permanent 
retention  of  the  user's  Scratch  file  and  common  block. 


FILE 

TABLE  4 DATA  BASE  FILES  REQUIRED 
FILE  DESCRIPTION  (AND  FUNCTION) 

IRIS  USE 

SUCAT 

Intelligence  Subject  Catalog, 
(User  Selects  Level  of  Detail) 

Controls  IRIS 
Processes 

INC 

Information  Need  Categories, 

(User  Selects  Needs  Related  to  Subject) 

Controls  RIM 
Analysis 

INC  DEF 

Definitions  for  Above  INCs, 
(User  Familiarization) 

Terminal  Display 

SUMAT 

Subject  Matrix,  for  Subject  (Correlated  INCs 
to  Collection  Discipline  for  each  Subject) 

2 Dimensions  of 
RIM 

AS  CAP 

Asset  Capabilities  or  External  Data  File 
Textual  Data,  (User  Review) 

Text  Review 
Process 

SYSCAT 

Info  System  Output  Catalog, 

(ASCAP  Summary  & Function  Correlation) 

RIM  Solutions  & 
Directory 

SYSMAT 

Info  System  Output  Matrix, 

(Ability  of  Output  to  Satisfy  INCs) 

3rd  Dimension  of 
RIM 

INTSIG 

Intelligence  Signatures  (Subject  Correlated 
Tech  Characteristics  & Resolutions  for 
ELINT,  RADINT  & PHOTINT) 

Display  for  Tech- 
nical Compatibility 

TRACK 

Predefined  Flight  Paths 
(Acquisition  Analysis) 

COLOP  Route 
Profiles 

MSGFORM 

Sample  Message  Forms  (Various  Tasking  Messages) 

Display  & Hardcopy 

TUT 

Tutorial  Files,  (Displayed  to  User  During 
IRIS  Process) 

Instruct  IRIS  User 
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TABLE  5 SPECIFIC  DATA  BASE  FILE  REQUIREMENTS 
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o The  SUCAT  file  shall  contain  a structured  list  of  intelligence  subjects 
arranged  so  as  to  associate  general  subject  categories  with  succeeding 
levels  of  more  definitive  subject  categories. 

o The  INC  file  shall  contain  candidate  elements  that,  when  selected  by 
the  user,  represent  what  he  needs  to  know  about  a particular  subject. 

The  INC  definition  file  shall  identify  the  basic  characteristics  of 
each  INC. 

o The  SUMAT  file  shall  contain  a structured  data  array  that,  indexed  by 
specific  intelligence  subjects,  identifies  the  appropriate  INCs  that 
can  or  cannot  be  satisfied  by  a particular  collection  discipline  or  a 
particular  category  of  non-perishable  intelligence  files. 

o Each  ASCAP  file  shall  contain  a descriptive  summary  of  a specific  output 
from  a particular  information  system.  The  information  systems  shall  be 
either  collection  systems  or  non-perishable  intelligence  files.  The 
ASCAP  file  for  each  output  shall  contain  information  system  identifiers, 
content  and  quality  discussions  of  the  output,  output  access  methods, 
and,  if  applicable,  information  system  technical  and  operational 
characteristics. 

o The  SYSCAT  file  shall  contain  an  identification  of  the  information  system 
outputs,  a brief  summary  of  each  output,  And  a functional  directory  of 
key  displays  applicable  to  each  output.  The  SYSCAT  shall  be  arranged 
so  as  to  associate  the  outputs  with  their  collection  system  or  intelligence 
data  file  sources. 

o The  SYSMAT  file  shall  contain  structured  data  statements  reflecting  the 
ability  of  particular  information  system  outputs  to  satisfy  each  of  the 
information  need  categories. 

o The  INTSIG  files  shall  contain  intelligence  signature  data  corresponding 
to  particular  selected  intelligence  subjects.  Each  subject  shall  be 
correlated  with  families  of  active  emitter  characteristics,  imagery 
resolutions,  or  radar  cross-sections,  as  applicable. 

o The  TRACK  file  shall  be  a structured  data  array  containing  identifiable 
PARPRO  and  non-PARPRO  track  profiles  for  use  in  airborne  acquisition 
opportunity  analyses.  These  data  shall  be  assembled  in  terms  of  track 
identifiers  and  the  location  and  altitude  of  the  event  points. 

o The  MSGFORM  files  shall  contain  exemplary,  standard  messages  to  facilitate 
communication  of  acquisition  requirements  and  requirements  for  data 
distribution  and  special  data  processing. 

o The  Tutorial  files  shall  contain  clear,  user-oriented  instructions  and 
information  regarding  the  executable  controls  of  sequence  alternatives, 
selection  processes,  and  data  displays. 
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C.  ANALYSIS  REQUIREMENTS 


I.  Derived  Data 

The  data  to  be  derived  by  analysts  during  the  development  of  IRIS  will 
include : 

o That  which  is  germane  to  the  generation  of  RIM  solutions  (solutions 
to  the  posed  query). 

o That  which  is  required  to  complete  an  INTSIG  data  base. 

The  RIM-related  data  to  be  developed  uner  the  sponsorship  of  this  contract 
are:  the  query  Subject  Matrix  (SUMAT)  and  the  Information  System  Output 

Analysis  Matrix  (SYSMAT)  elements.  The  SUCAT  and  the  INCs  had  been  derived 
by  Martin  Marietta  Aerospace  prior  to  the  initiation  of  this  contract. 

The  SUMAT  preparation  was  specified  by  the  following  criteria: 

o It  is  acceptable  for  a specific  subject  SUMAT  to  reflect  more 
capability  than  can  be  expected  from  a particular  collection 
discipline  within  the  current  state-of-the-art.  These  data  are 
intended  to  reflect  state-of-the-art  capability  associated  with  a 
collection  discipline  rather  than  a specific  information  system 
capability.  The  subsequent  correlations  with  information  systems 
associated  with  the  particular  collection  discipline,  will  screen 
out  any  erroneous  associations. 

o The  identification  of  an  observable  with  a SUMAT  subject,  as  the 
precursor  to  association  of  a collection  discipline  with  the 
subject,  should  avoid  nontypical  situations.  For  example,  although 
the  non- literal  emanations  from  an  electric  power  generation  facility 
could  be  detected  by  ELINT  sensors,  this  type  of  sensor  is  not  used 
for  this  purpose. 

c The  logical  sum  of  the  SUMATs  for  IRIS  subjects  within  the  same 
indenture  level,  will  be  the  SUMAT  for  the  next  higher  indenture 
leve  1 . 

The  SYSMAT  preparation  was  specified  by  the  following  criteria: 

o The  Output  Content  section  of  the  applicable  ASCAP  will  be  the 
source  of  the  determination  of  what  information  needs  may  be 
satisfied  by  the  output. 


o The  Output  Quality  section  of  the  applicable  ASCAP  will  be  the 
source  of  the  determination  of  how  well  the  information  needs  may 
be  satisfied  by  the  output. 

The  INTSIG  data  to  be  developed  will  serve  two  ends: 

o Provide  descriptors  of  observable  signatures  of  either  individual 

subjects  or  classes  of  subjects  as  the  basis  for  technical  validation 
of  the  information  systems  identified  in  the  RIM  process, 
o Provide  required  data  on  potential  query  subjects  that  will  be  used 
in  selected  acquisition  opportunity  analyses. 

The  INTSIG  data  required  were  specified  as  follows: 

o For  imaging  signatures;  the  imaged  resolutions  required  to  develop 
the  four  levels  of  identification  defined  by  the  IRIS  information 
need  categories.  This  will  be  required  for  all  IRIS  subjects 
capable  of  being  identified  by  imaging  outputs, 
o For  ELINT  signatures;  the  radar  type,  function  and  RF  ranges  for 
each  IRIS  subject  that  may  typically  be  associated  with  some  type 
of  pulsed  emitter.  These  data  will  also  be  augmented  by  other 
radar  technical  descriptors  that  might  be  appropriate  to  a data 
acquisition  opportunity  analysis. 

o For  RADINT  signatures;  typical  radar  cross  sections  at  F and  I band 
RFs  for  those  IRIS  subjects  that  could  be  detected  or  tracked  by 
either  surface  or  airborne  radar. 

o For  acoustic  signatures;  the  frequency  of  a query  subject  primary 
and  secondary  sources,  (both  identified  to  source  type)  and 
iuentif ication  of  typical  noise  sources.  These  data  will  be  dev- 
eloped for  all  IRIS  subjects  capable  of  being  detected  or  tracked 
by  passive  acoustic  sensors. 

o For  infrared  (IR)  signatures;  peak  intensities  of  query  subject 

emitters  relative  to  an  expected  background  under  both  day  and  night 
conditions.  These  data  will  be  logically  limited  to  those  subject 
emitters  capable  of  being  detected  by  state-of-the-art  IR  sensors. 


2.  Computations 

Computations  to  be  made  within  IRIS/IOC  will  include  four  information 
acquisition  opportunity  exercises: 
o Airborne  S1GINT 
o Airborne  RAD1NT 
o Airborne  PHOT 1 NT 
o Surface  RADINT 

These  evaluation  requirements  were  specified  to  include  performance  measures 
and  method  of  analysis.  The  first  three  will  be  limited  to  programs 
characterized  by  established  routes;  i.e.,  no  user-input  route  data  will 
be  accommodated. 

The  specific  requirements  were  specified  by  the  following  criteria: 

o Airborne  SIGINT  outputs  will  include  cumulative  acquisition  time 
against  an  IRIS-user  designated  point  target  for  each  route  that 
an  identified  information  system  is  associated  with.  The  analysis 
will  assume  geometric  rather  than  radio  line-of-sight  as  a 
concession  to  the  omission  of  weather  and  EMCON  effects  on  perfor- 
mance. Each  segment  of  each  applicable  route  will  be  described  in 
terms  of  earth-centered  vectors,  as  will  be  the  designated  target. 
Collection  time  on  a segment  will  be  computed  in  IRIS  by  determining 
the  time,  on  the  segment,  when  the  target  is  within  line-of-sight. 
The  identified  information  system's  nominal  mission  speed  will  be 
used.  Orbit  segments  will  be  considered  as  separate  discrete 
segments . 

o Airborne  RADINT  outputs  will  include  cumulative  acquisition  time, 
for  each  route,  against  a user-designated  boundary  of  an  area 
target,  and  the  fraction  of  this  boundary  against  which  collection 
could  occur.  The  analysis  will  assume  geometric  rather  than  radio 
line-of-sight  (although  normally  typical)  as  a concession  to  the 
omission  of  weather  and  sea-state  effects  on  performance.  Each 
segment  of  each  applicable  route,  and  the  designated  boundary  target 
strip  will  be  described  in  terms  of  earth-centered  vectors. 
Collection  time  on  a segment  will  be  computed  hv  IRIS  by  determining 
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the  time,  on  the  segment,  when  at  least  one  point  on  the  target 
strip  is  within  line-of-sight . The  identified  information  system's 
nominal  mission  speed  will  be  used.  Target  strip  coverage  will 
be  computed  in  IRIS  by  determining  the  Boolean  sum  of  all  segments 
of  the  target  strip  against  which  collection  could  occur.  This  will 
include  any  route  segment  from  which  the  target  strip  is  within 
line-of-sight.  Radar  performance  will  be  enabled  by  the  use  of  a 
partial  solution  of  the  standard  radar  range  equation.  This  will 
be  included  in  the  ASCAP  record  associated  with  the  information 
system  being  evaluated.  This  partial  solution  will  consider  all 
parameters  except  the  target  cross-section  parameter  which  would  be 
input  by  the  IRIS  user. 

o Airborne  PHOTINT  outputs  will  include  minimum  and  maximum  depression 
angles  of  the  line-of-sight  from  any  applicable  route  segment  to  a 
user-designated  boundary  of  an  area  target,  and  the  slant  ranges 
associated  with  these  depression  angles.  Each  segment  of  each 
applicable  route  will  be  described  by  earth-centered  vectors  as 
will  be  the  boundary  target  strip.  The  analysis  will  consider  the 
orientation  of  the  camera  relative  to  the  platform  roll  axis. 

Slant  ranges  along  the  boundary  lines-of-sight  will  follow  routinely. 

o Surface  RADINT  outputs  will  include  data  describing  the  slant 

range-altitude  envelope  associated  with  a surface  radar  operating 
against  an  IRIS  user-designated  airborne  target  (the  subject  of  the 
current  information  requirement).  This  output  will  be  implemented 
by  the  use  of  a partial  solution  of  the  standard  radar  range  equation. 
This  will  be  included  in  the  ASCAP  record  associated  with  the  infor- 
mation system  currently  being  considered.  This  partial  solution 
will  consider  all  radar  variables  except  the  gain  and  target 
cross-section  parameters.  The  gain  will  be  computed,  within  this 
analysis,  over  a vertical  angle  through  the  radar  boresight  corres- 
ponding to  the  25  percent  range  points.  Boresight  gain  and  vertical 
half  power  beam  width,  from  the  ASCAP  record  associated  with  the 
current  information  system  will  be  used  for  this  computation. 


25 


In  each  of  the  above  data  acquisition  opportunity  evaluations,  the  inputs 
required  should  be  in  keeping  with  the  user's  normal  way  of  th.nking  (e.g., 
expression  of  locations,  dates,  and  times).  When  the  user  is  required  to 
transfer  data  from  an  ASCAP  or  INTSIG  record,  it  should  be  identified  in 
the  same  manner  as  in  the  source  record.  Generic  identifications  will  not 
be  used. 
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SECTION  V 


SOFTWARE  DEVELOPMENT 

The  established  software  requirements  formed  the  specification  for  IRIS 
development.  The  end  product  is  an  user-oriented  information  display  system. 
The  software  requirements  of  Section  IV  present  the  specifications  for  com- 
puter hardware,  software  operating  system,  programming  language,  data  base 
structure,  man/machine  interface,  and  software  operations  that  controlled 
the  software  development.  Several  enhancement  techniques  were  incorporated 
during  this  development.  The  software  was  developed  on  the  basis  of  two 
major  functional  divisions,  i.e.,  data  base  file  build  programs  and  user- 
controlled  executable  IRIS.  The  user-oriented  capabilities  of  IRIS  are  con- 
tinuing to  be  validated. 

A.  SOFTWARE  ENHANCEMENT  TECHNIQUES 

IRIS  software  development  was  significantly  enhanced  by  several  implementa- 
tion techniques.  These  techniques  were  incorporated  after  recognizing  the 
similarity  of  certain  data  files,  the  analysis  dependency  on  the  IRIS  subject 
list,  the  need  for  free-form  textual  files,  and  the  desire  to  interface 
through  different  user  terminals. 

A basis  for  a common  software  development  approach  was  the  functional  simi- 
larity of  several  classes  of  files;  e.g.,  the  various  Asset  Capability 
(ASCAP)  files  and  the  different  collection  system  Intelligence  Signature 
(INTSIG)  files.  In  the  case  of  the  ASCAP  files,  the  structure  was  defined 
so  that  all  types  of  information  systems  could  be  accommodated  by  the  same 
ASCAP  format.  In  the  case  of  the  INTSIG  files,  common  retrieval  and  presen- 
tation software  was  developed  to  use  a query  subject  cross  reference  record 
(unique  for  each  INTSIG)  in  conjunction  with  an  unstructured  assembly  of 
technical  observables.  The  elements  of  these  observables  were  appropriately 
flagged  in  the  cross  reference  record. 

The  multiple  use  of  the  IRIS  subject  list  in  support  of  different  IRIS  anal- 
yses and  presentations  identified  an  opportunity  for  a single  indexing 
vector  map  to  be  used  in  support  of  several  analyses  (e.g.  , the  RIM  analysis 
and  the  subject-peculiar  INTSIG  presentation).  The  IRIS  conversion  of  the 
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SUCAT  indentured  identifications  into  an  indexed  array  was  amenable  to 
efficient  software  manipulation. 

Certain  IRIS  files  (e.g.,  ASCAP  and  MSGFORM)  do  not  require  preprocessing 
and  can  be  stored  in  the  data  base  in  any  order  convenient  to  the  generating 
process.  These  file  records  were  assigned  unique  data  base  names.  The 
utility  programs  in  RSX-HD,  the  IRIS  computer  operating  system,  were  used 
to  access  these  files  instead  of  burdening  IRIS  with  additional  software 
requirements  to  develop  vector  maps  or  accessing  software. 

The  use  of  SEND  and  RECEIVE  subroutines  instead  of  the  normal  Fortran  read / 
write  statements  were  used  to  facilitate  the  efficient  evolution  from  an 
IOC/VT-52  terminal  to  the  expected  FOC  Univac  1652  terminal.  This  software 
technique  assured  conversion  simplicity  in  that  only  two  well  identified 
routines  need  to  be  modified  when  different  terminal  devices  are  incor- 
porated. 

B.  FILE  BUILD  PROGRAMS 

IRIS  file  build  programs  reorganize  the  analyst  created  data  base  files  for 
easy  access  during  IRIS  execution.  The  functional  flow  of  Figure  2 illus- 
trates the  relationship  of  the  data  base  files  to  these  interim  programs. 

This  figure  indicates  that  three  classes  of  data  base  files  are  used 
directly  in  the  IRIS  execution.  The  remaining  files  require  associated  file 
build  programs  to  reorder  and  vector  map  the  data  for  efficient  operations 
and  correlations  during  execution.  The  restructured  files  generated  by 
these  programs  are  stored  on  the  disk  subsystem  for  use  in  IRIS  execution. 

C.  IRIS  SEQUENTIAL  EXECUTION 

The  sequential  execution  division  of  IRIS  performs  the  screening  process  to 
determine  candidate  information  system  outputs,  then  allows  the  user  easy 
access  to  pertinent  stored  information  related  to  these  outputs.  This  divi- 
sion of  IRIS  is  illustrated  by  the  sequential  execution  flow  of  Figure  2. 

The  software  for  this  division  was  developed  so  that  a user  can  follow 
either  a predefined  execution  sequence  or  an  optional  execution  sequence. 
Either  sequence  allows  the  user  to  proceed  through  the  functional  operations 
of  sign-on,  RIM  analysis,  ASCAP  textual  review,  and  finally,  IRIS  Log  review. 
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Figure  2 IRIS  Functional  and  Sequential  Execution 
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The  subroutines  developed  to  support  these  operations  are  functionally  iden- 
tified in  Table  6.  The  optional  execution  sequence  was  developed  to  allow 
an  experienced  user  to  exercise  various  operations  somewhat  independent  of 
one  another.  The  implemented  IRIS  is  a stand-alone,  user-oriented  system 
that  provides  rapid  solutions  to  posed  information  requirements. 

D.  VALIDATED  IRIS  CAPABILITIES 

Reviews  and  demonstrations  of  IRIS  have  validated  user/machine  interactive 
capabilities,  interpretation  of  information  requirements,  display  of  relevant 
information  system  data,  and  qualitative  user  comparisons.  A mid-term  re- 
view was  held  of  the  RIM  analysis  portion  of  IRIS.  Included  in  this  review 
was  the  presentation  of  data  base  files  pertinent  to  the  RIM  analysis,  the 
necessary  analysis  software,  and  the  tutorials  to  be  incorporated  for  user 
instruction.  This  early  review  served  to  validate  the  basic  RIM  concept  and 
provided  a basis  for  specifying  requirements  relative  to  command  flexibility 
and  user  interactions.  A prototype  version  of  IRIS  was  delivered  to  IPAC/ 
IWC,  Camp  H.  M.  Smith,  Honolulu,  Hawaii,  in  early  December  1976.  Subsequent 
IPAC  and  Martin  Marietta  Aerospace  operations  of  IRIS  have  validated  its 
basic  concepts  and  have  fine-tuned  the  man/machine  interface  requirements. 
Further  validation  of  IRIS  will  occur  starting  with  the  technical  capa- 
bilities demonstration  at  IPAC/IWC  the  first  week  of  February  1977. 
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TABLE  6 IRIS  FUNCTIONAL  OPERATIONS 


FUNCTIONAL  OPERATIONS  ALLOWS  THE  IRIS  USER  TO: 

o Sign-On  Enter  his  name  for  IRIS  Log  identification 

Read  the  introductory  tutorial 
Input  an  information  requirement 

o RIM  Select  an  intelligence  subject 

Select  a set  of  information  need  categories 
Examine  the  RIM  solution  candidates 

o ASCAP  Review  Display  ASCAP  files  of  output  attributes 

Display  intelligence  signatures  of  the  subject 
Analyze  acquisition  opportunities  of  the  system 
Display  message  forms  for  possible  tasking 

o Log  Review  Display  IRIS  Log  of  transactions  during  dialogue 

o Sign-Off  Stop  IRIS  execution,  IRIS  processing  completed 
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SECTION  VI 


DATA  BASE  AND  ANALYSIS  METHODS  DEVELOPMENT 

A.  DATA  BASE 

1.  Assembled  Data 

The  data  base  components  which  fall  into  this  category  are  the: 
o ASCAP  (Asset  Capability)  Files 
o SYSCAT  (Information  System  Output  Catalog) 
o INTSIG  (Intelligence  Signature)  Files 
o MSGFORM  (Message  Form)  Files 
o TRACKS  (Data  Acquisition  Track)  File 

a.  Asset  Capability  (ASCAP)  Files 

The  ASCAP  files  serve  two  functions  in  IRIS: 

o A central  location  where  descriptors  of  the  information  system  and 
information  system  output  are  assembled  for  the  user's  review, 
o The  operational  location  within  IRIS  from  which  a user  can  branch 
to  either  more  detailed  analyses  of  the  information  system  or  to 
the  initiation  of  output  acquisition  actions.  Either  of  these 
options  require  data  which  are  stored  in  ASCAP  files. 

The  support  of  these  two  ASCAP  functions  implies  a variety  of  data  for  any 
one  information  system  and  further  variations  for  different  types  of  infor- 
mation systems.  The  construction  of  the  ASCAP  Was  defined  to  permit  the 
inclusion  of  many  data  variations  extracted  from  reference  reports  and/or 
interviews  without  attempting  to  force  such  data  into  an  artificially  con- 
strained format.  To  facilitate  an  easier  review  by  the  IRIS  user,  the  major 
sections  were  structured  in  an  indentured  manner.  For  example,  the  Output 
Content  section  describes  all  the  information  in  the  output,  including,  as 
applicable,  such  things  as: 

o Generic  output  information 

o Geographic  constraints  associated  with  the  output  information, 
o Processing  effects  on  the  information. 

o The  autonomy  of  a single  output  (relative  to  sequential  issues  of 
the  output) . 
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To  highlight  each  of  these,  a major  indenture  is  used  with  subindentures  if 
the  major  division  is  modified  or  requires  finer  grained  detail. 

It  was  apparent  that  some  of  the  sections  within  a given  ASCAP  would  either 
be  very  detailed  at  IOC  or  else  would  grow  rapidly  as  the  IRIS  user  became 
aware  of  more  facts  about  the  information  system  and  added  them  to  a spe- 
cific ASCAP  file.  Such  incremental  growth,  if  not  disciplined,  could  in- 
hibit IRIS  from  leading  users  rapidly  to  the  selection  of  the  most  promising 
information  system  outputs,  if  the  user  had  excessive  ASCAP  material  to 
review.  Accordingly,  it  was  determined  that  a brief  (less  than  a single 
display  page)  executive  summary  was  needed.  Information  system  and  output 
highlights  were  assembled  in  this  lead  section.  This  will  permit  the  user 
to  accomplish  one  of  two  ends: 

o Establish  whether  or  not  the  content  of  a particular  ASCAP  file 
would  be  relevant  to  the  current  query,  and  thus  minimize  his  in- 
volvement in  manual  review  efforts. 

o Enable  him  to  validly  reject  the  particular  information  system  with- 
out having  to  review  a complex  ASCAP  record. 

To  further  facilitate  the  use  of  these  data,  each  ASCAP  file  has  been  pagina- 
ted and  the  user  can  determine  from  a table  of  contents  following  the  execu- 
tive summary  where  he  should  look  for  data  of  particular  interest  to  him. 

b.  Information  System  Output  Catalog  (SYSCAT) 

The  SYSCAT  serves  two  functions  in  IRIS: 

o It  provides  abbreviated  summaries  of  the  salient  attributes  of  in- 
formation system  outputs  which  are  used  to  identify  candidate  solu- 
tions to  queries.  Sufficient  information  about  each  output  is 
presented  to  allow  the  user  to  decide  on  the  value  of  additional 
review  of  a displayed  solution. 

o It  provides  a record  in  which  identifiers  of  other  pertinent  files 
or  analysis  procedures,  uniquely  associated  with  the  output,  can  be 
stored.  These  identifiers  enable  subsequent  software  access  of  the 
appropriate  intelligence  signature  files,  data  acquisition  oppor- 
tunity analysis  and  applicable  standard  message  formats.  These 
identifiers  also  serve  as  indicators  of  the  existence  or 
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non-existence  of  specific  file  records.  Every  SYSCAT  element  should 
be  associated  with  an  ASCAP  record.  However,  in  the  event  that  an 
ASCAP  has  not  yet  been  developed,  a SYSCAT  element  may  still  be  dis- 
played as  a potential  query  solution. 

c.  Intelligence  Signature  (INTSIG)  Files 

INTSIG  files  were  conceived  as  repositories  of  data  that  would  serve  two 
objectives : 

o Provide  data  for  user  review  and  software  operations , the  results 
of  which  would  validate  (or  invalidate)  the  technical  compatibility 
between  a given  information  system  and  a given  subject, 
o Provide  data  on  information  requirement  subjects  (the  targets  of 
information  system  data  acquisition)  which  would  be  germane  to  the 
evaluation  of  data  acquisition  opportunities. 

It  was  recognized  that  accomplishment  of  either  objective  should  be  charac- 
terized by  a rapid  convergence  to  the  specifically  applicable  signature. 

The  value  of  INTSIG  information  relative  to  the  solution  of  an  information 
requirement  would  be  small  (as  compared  to  that  which  would  be  derived  from 
review  of  an  ASCAP  file)  and  so  an  inordinately  long  analysis  should  be 
avoided.  Since  IRIS  software  keeps  track  of  the  current  query  subject,  it 
was  only  necessary  to  define  INTSIG  pointers  that  would  enable  the  software 
to  retrieve  and  present  the  signature  data  related  to  a given  query  subject. 
This  was  accomplished  by  development  of  subject  signature  to  subject  cate- 
gory correlations  wherein  the  subject  categories  were  associated  with  sig- 
natures related  to  specific  Collection  disciplines. 

It  was  also  recognized  that  the  type  of  information  presented  via  the  INTSIG 
would  vary  considerably  from  one  signature  type  to  another.  For  example, 
ELINT  signatures  can  identify  applicable  radars  and  associate  enough  opera- 
ting or  technical  data  to  confirm  the  identified  information  system;  whereas 
PHOTINT  signatures  can  only  express  resolution  required  to  achieve  different 
levels  of  identification.  Consequently,  it  was  appropriate  to  allow  the 
INTSIG  files  to  vary  in  format  for  different  collection  disciplines  as  re- 
quired. These  INTSIG  files  were  developed  for  IRIS: 
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o ELINT  - Radar  identification,  primary  function,  radio  frequency 
ranges  and  vertical  beam  widths. 

o PHOTINT  - Resolution  required  to  achieve  the  four  levels  of  identi- 
fication specified  by  IRIS  information  need  categories, 
o RADINT  - Radar  cross  section  vs.  aspect  angle  at  a reference  radio 
frequency. 

ACINT  and  IRINT  signature  data  were  not  developed  for  IRIS /IOC. 

d.  Message  Form  (MSGFORM)  Files 

The  MSGFORM  files  are  models  of  the  standard  messages  which  are  to  be  used 
to  formalize  an  IRIS  user's  informal  request  to  access  a particular  infor- 
mation system  output.  These  models  can  include  action  and  information 
addressees  identified  and  with  all  the  message  elements,  that  the  informa- 
tion system  protocol  requires. 

e.  Data  Acquisition  Track  (TRACKS)  File 

The  data  for  this  file  were  obtained  from  sets  of  established  data  acquisi- 
tion tracks  and,  for  IRIS/IOC,  required  only  a minimum  of  analyst  editing. 

2.  Derived  Data 

These  files  contain  the  source  data  by  which  queries  are  posed  to  the  system 
and  from  which  candidate  solutions  to  queries  are  derived.  They  are: 
o Intelligence  Subject  Catalog  (SUCAT) 
o Information  Need  Category  (INC)  File 
o Subject  Matrix  (SUMAT)  File 

o Information  System  Output  Analysis  Matrix  (SYSMAT)  File 

a.  Intelligence  Subject  Catalog  (SUCAT) 

As  noted  in  Section  III,  the  concept  of  a query  subject  as  the  principal 
focus  of  the  IRIS  user's  information  requirement  implied  the  need  for  an 
IRIS  subject  list  with  which  the  subject  of  a given  query  could  be  cor- 
related. The  set  of  subjects  that  compose  the  SUCAT  was  developed  under 
sponsorship  of  a Martin  Marietta  new  space  Independent  Research  and  Develop- 
ment (IRAD)  Task. 
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b.  Information  Need  Category  (INC)  File 

As  noted  in  Section  III,  INC  data  is  a categorization  of  what  is  required 
to  be  determined  about  a query  subject.  As  such,  it  is  used  in  two  ways: 
o As  a complement  to  the  SUCAT  correlation  in  the  presentation  of  a 
query  to  IRIS . 

o As  the  focus  of  the  analyses  described  in  Subsections  c.  and  d. 

The  INC  data  was  developed  prior  to  the  development  of  IRIS  under  Martin 
Marietta  Aerospace  IRAD  sponsorship. 

c.  Subject  Matrix  (SUMAT)  File 

As  noted  in  Section  III,  the  derivation  of  solutions  to  user  queries  was 
accomplished  by  forming  the  dot  product  of  two  n-tuple  vectors  where  n is 
the  cardinal  of  the  information  need  categories.  One  of  these  is  a unit 
vector  that  describes  which  INC  could  be  satisfied  by  outputs  of  a collec- 
tion discipline  associated  with  observables  of  an  IRIS  subject.  The  method 
by  which  the  first  of  these  vectors  (the  SUMATs)  are  derived  is: 

o All  observables  of  a given  subject  are  identified.  The  collection 
discipl ine(s)  that  could  detect  or  measure  each  of  these  observables 
are  identified.  Also,  the  types  (as  indicated  by  their  subject 
matter)  of  intelligence  files  which  may  be  associated  with  the 
subject  are  identified. 

o Which  information  need  categories  could  be  satisfied,  to  any  degree, 
by  each  identified  collection  discipline  or  file  type  are  identified. 
This  determination  is  independent  of  a specific  information  system 
or  intelligence  file. 

o SUMATs  for  all  subjects  at  the  same  indenture  level  are  then  logi- 
cally summed  to  form  the  SUMAT  for  the  next  higher  level  of  subject 
indenture . 

o The  subject's  membership  in  both  of  the  following  subject  supersets 
are  designated. 

o Land,  air /space,  riverine/ocean 

o Equipment/installation,  activity/event , organization/structure 
This  subject  superset  designation  enables  the  IRIS  query  solution 
analysis  to  eliminate  illogical  solutions. 
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d.  Information  System  Output  Analysis  Matrix  (SYSMAT)  File 


The  second  of  the  two  vectors  referred  to  in  Subsection  c.  above  is  the 
SYSMAT.  This  is  a vectoral  summary  of  how  well  a specific  information  system 
output  satisfies  the  INC  elements.  The  method  by  which  this  vector  is 
derived  is  to: 

o Determine  which  INC  elements  can  be  satisfied  as  presented  by  the 
Output  Content  section  of  the  related  ASCAP. 
o Determine  how  well  these  INC  elements  will  be  satisfied, as  presented 
by  the  Output  Quality  section  of  the  related  ASCAP. 
o Designate  the  applicability  of  the  output  to  the  subject  supersets 
listed  in  Subsection  c.  above.  Verifying  subject  superset  commona- 
lity will  screen  out  illogical  query  solutions. 

B.  ANALYSIS  METHODS 

Methods  were  developed  for  acquisition  opportunity  evaluation  within  IRIS. 

1.  Airborne  SIGINT 

This  analysis  is  implemented  by  the  following  method: 

o Incremental  testing  of  each  track  segment  to  identify  at  least  one 
valid  point  from  which  collection  could  occur, 
o For  candidate  segments,  determination  of  the  distance  along  the 
segment  when  target  is  within  line-of-sight  and  conversion  of  this 
distance  to  elapsed  time  using  input  platform  speed, 
o Accumulation  of  collection  time  for  all  eligible  segments  on  a given 
track  and  outputing  this  cumulative  time  as  a measure  of  the  plat- 
form's capability  on  that  route. 

o Repetition  of  the  above  for  each  track  identified  with  the  informa- 
tion system  in  the  related  ASCAP  record. 

Required  inputs  by  the  user  are  latitude,  longitude,  and  elevation  of  the 
target  point  and  information  system  speed  (from  the  pertinent  ASCAP  file) . 

2.  Airborne  PHOTINT 

This  analysis  is  implemented  by  the  following  method: 
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o Incremental  determination  of  which  track  segments  are  candidates 
for  collection  based  on  the  relationship  between  line-of-sight 
vector  and  sensor  boresight  orientations  to  at  least  one  point  on 
the  user-designated  target  strip. 

o For  the  candidates  identified  above,  determination  that  geometric 
line-of-sight  to  at  least  one  point  on  the  target  strip  exists, 
o Determination  of  minimum  and  maximum  slant  ranges, 
o Determination  of  minimum  and  maximum  depression  angles,  associated 
with  these  slant  ranges. 

o Cumulative  segment  testing  of  depression  angles  to  enable  the  output 
for  the  entire  track  to  reflect  best  and  worst  collection  capability, 
o Repetition  of  the  above  for  each  track  identified  with  the  informa- 
tion system  in  the  related  ASCAP  record. 

Required  inputs  by  the  user  are  latitudes,  longitudes,  and  elevations  of  the 
two  end  points  of  the  target  strip  that  form  a boundary  of  a target  area  of 
interest. 

(i 


SECTION  VII 


SYSTEM  LIMITATIONS 

Three  principal  categories  of  IRIS  limitations  are  discussed  in  this  section: 
o System  design  and  system  operations 
o Data  base 
o Analysis  methods. 

A.  SYSTEM  DESIGN  AND  SYSTEM  OPERATIONS  LIMITATIONS 

This  subsection  discusses  identified  display  and  utility  limitations  of  IRIS. 
Those  thus  far  identified  do  not  represent  weaknesses  in  the  basic  system, 
but  rather,  convenience  and  sophistication  omissions.  The  limitations  pre- 
sently identified  are  summarized  below: 

o Excessive  user  review  and  decision-making  actions  are  required  within 
the  current  IRIS  process.  IRIS  design  was  predicated  on  the  user 
being  responsible  for  making  comparisons  between  system  capabilities 
and  information  requirements  as  the  basis  of  his  decision-making.  If 
critical  threshold  values  were  available  for  these  comparisons,  this 
review  and  decision  process  could  be  streamlined  and  included  to  a 
greater  degree  in  the  IRIS  software, 
o IRIS  design  was  originally  influenced  strongly  by  the  planned  use  of 
a dual  scope  display  terminal.  The  present  system  uses  only  a single 
scope  or  hardcopy  device  as  the  terminal.  The  late  change  in  display 
philosophy  lea  to  an  awkward  method  of  comparing  the  various  data 
from  ASCAP,  INTSIG,  message  form  and  scratch  files.  The  incorpora- 
tion of  the  dual  scope  display  terminal  would  alleviate  much  of  this 
limitation.  A related  software  deficiency  is  the  current  inability 
to  extract  parameter  values  from  an  ASCAP  for  automatic  transfer,  as 
input,  to  the  various  acquisition  opportunity  evaluations.  Correc- 
tion of  this  deficiency  involves  a fairly  major  software  modification, 
o Data  base  editing  of  IRIS  files  is  restricted  to  an  off-line  activity. 
The  data  base  files  cannot  be  revised  while  IRIS  is  being  operated. 
Changes  required  by  the  user  must  be  noted  for  later  editing  and 
rebuilding  of  the  file(s).  Editing  during  IRIS  operation  would  not 
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be  efficient.  However,  a semi-automated  process  could  be  implemented 
whereby  the  user  could  easily  leave  IRIS,  correct  the  desired  file, 
initiate  an  automatic  file  rebuild,  and  return  to  IRIS  to  continue 
his  analysis  with  corrected  file  information. 


B.  DATA  BASE  LIMITATIONS 


The  data  base  development  for  IRIS  was  not  as  complete  as  originally  planned, 
as  evidenced  by  the  lack  of  certain  classes  of  information  system  outputs 
and  data  voids  within  the  files.  IRIS  development  did  endeavor  to  define 
the  specific  file  elements  and  an  ensembled  arrangement  for  each  distinct 
type  of  information  system  appropriate  to  IRIS.  This  set  of  files  will  be  a 
useful  model  for  the  ultimate  expansion  of  the  various  IRIS  data  bases. 


Limitations  with  respect  to  specific  files  are  as  follows: 


1.  ASCAP  Limitations 


The  scope  of  the  IRIS  data  base  was  originally  expected  to  include  in  excess 
of  six  hundred  discrete  information  system  outputs,  each  of  which  would  be 
characterized  by  a unique  ASCAP  file.  Only  a small  portion  of  these  outputs 
were  eventually  included  in  the  IRIS  data  base.  However,  it  is  recognized 
that  of  the  potential  set  of  ASCAP  files,  many  may  not  be  viable  sources  for 
candidate  solutions  because  of  tasking  inaccessibilities  or  reporting  time- 
liness. The  lack  of  a broad  representation  of  outputs  does  present  a poten- 
tial weakness  in  the  effectiveness  of  the  IOC  system. 


INTSIG  Limitations 


The  INTSIG  data  base  file  was  originally  defined  to  relate  IRIS  intelligence 
subject  signatures  with  five  collection  disciplines.  Three  of  these  collec- 
tion discipline  to  subject  correlations  have  been  accomplished,  to  the  de- 
gree noted: 

o ELINT  - 95% 


o PHOTINT  - 100% 


o RADINT  - 25% 


The  other  two  collection  disciplines  required  data  that  could  not  be  speci- 
fied within  the  allotted  program  development  time.  However,  the  information 
system  outputs  included  in  IRIS/IOC  did  not  identify  ASCAP  records  that 
would  require  either  of  these  INTSIG  files. 
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3.  SYSCAT  Limitations 


The  SYSCAT  file  identifies  more  information  system  outputs  than  are  included 
in  corresponding  ASCAP  files.  Some  information  system  outputs  are  well 
enough  identified  to  permit  the  generation  of  a SYSMAT  record  but  sufficient 
data  was  not  available  to  justify  a corresponding  ASCAP  record.  Consequently, 
IRIS /IOC  can  identify  certain  candidate  solutions  that  cannot  be  reviewed  in 
detail . 

4.  MSGFORM  Limitations 

Data  in  this  file  are  derived  from  the  same  sources  as  is  the  ASCAP  Access 
Methods  data.  Consequently,  deficiencies  in  this  latter  area  will  also  be 
reflected  in  this  file. 

5.  Data  Base  Structure  Limitations 

The  SUMAT  and  SYSMAT  files,  from  which  the  RIM  analysis  is  derived,  were 
defined  without  prior  knowledge  of  the  number  or  type  of  candidate  solutions 
that  could  result.  More  information  need  category  satisfaction  resulted 
from  the  independent  SUMAT  and  SYSMAT  analyses  than  was  originally  antici- 
pated, with  many  of  the  RIM  solutions  being  illogical.  The  Application 
Category  assignments,  in  both  the  SYSMAT  and  SUMAT  analyses,  was  incorporated 
to  prevent  the  identification  of  these  illogical  solutions.  This  limited 
function  of  the  Application  Category  assignment  was  reflected  in  the  early 
definition  of  SUMAT  and  SYSMAT  formats  which  currently  cannot  accommodate 
any  additions  in  either  the  Information  Need  Categories  or  the  Application 
Categories.  This  latter  limitation,  particularly,  is  a significant  handicap 
relative  to  correction  of  the  surplus  solution  syndrome. 

C.  ANALYSIS  METHOD  LIMITATIONS 

Various  analyses  were  required  to  support  the  generation  of  the  IRIS  data 
base  files.  The  analysis  methods  used  were  simplified  wherever  the  results 
would  not  adversely  influence  the  final  results.  Also,  certain  performance 
refinements  were  not  included  in  the  ASCAP  descriptions  of  sensors  nor  re- 
flected in  the  sensor  performance  that  could  be  required  in  selected  acqui- 
sition opportunity  evaluations. 
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As  examples  of  these  limitations,  IRIS/IOC  did  not  include  atmospheric  or 
clutter  effects  in  the  RADINT  performance  evaluations  even  though  developed 
models  of  these  effects  were  available.  In  the  case  of  airborne  ELINT  in- 
formation systems,  the  corresponding  ASCAP  descriptions  did  not  characterize 
DF  accuracy  as  a function  of  target  emitter  RF.  The  acquisition  opportunity 
analyses  included  in  the  IRIS/IOC  do  not  evaluate  all  possible  types  of  in- 
formation systems.  Also,  the  analyses  included  are  based  on  somewhat 
simplified  methods  and  limit  the  number  of  target  and  information  system 
parameters . 

Sophistication  of  these  analyses  should  be  postponed  until  the  user  of  IRIS 
becomes  familiar  with  the  results  of  these  analyses  and  can  determine  that 
such  data  will  be  useful  in  the  execution  of  IRIS  decisions. 


SECTION  VIII 


CONCLUSIONS 

IRIS/IOC  is  a functionally  complete  intelligence  data  support  system  that 
can  be  used  to  facilitate  the  identification  and  selection  of  information 
system  outputs,  as  solutions  to  posed  queries.  IRIS  consists  of  an  all- 
source data  base,  working  files  developed  on-line  to  support  the  analysis  of 
user's  queries,  and  a flexible  operating  command  structure  responsive  to  a 
functional  man-machine  interface.  The  system  has  been  designed  to  permit 
intimate  involvement  by  the  user.  This  includes  the  specification  of  pro- 
blems to  the  system,  the  presentation  of  stored  and  generated  data,  and  the 
interpretation  of  presented  data  in  the  form  of  user's  decisions.  The  system 
was  also  structured  to  encourage  growth  of  both  the  various  data  bases  and 
the  software-controlled  procedures  and  presentations.  IRIS/IOC  can  be  con- 
sidered a prototype  system.  The  evolution  into  IRIS/FOC  would  require  expan- 
sion of  the  various  types  of  data  files  using  the  formats  defined  during 
this  development.  Data  and  software  enhancements  that  could  be  imposed 
would  be  required  only  to  reduce  the  time  required  for  the  IRIS  analysis 
processes . 

IRIS  software  design  was  defined  to  accommodate  both  the  IOC  system  func- 
tional requirements  and  the  evolution  into  an  enhanced  FOC  system.  Analyst- 
created  data  files  were  so  defined  that  incremental  growth  of  this  data  base 
could  be  handled  with  no  impact  on  software  design.  IRIS  data  file  build 
software  has  been  designed  so  that  incremental  additions  to  the  data  base 
can  be  reflected  in  these  IRIS  files  without  the  system  having  to  be  taken 
off-line.  IRIS  system  software  design  has  been  structured  so  that  eventual 
use  of  different  terminal  devices  will  require  minimal  changes  to  the  soft- 
ware interface.  Inherent  RSX-11D  (the  operating  system  software)  capabili- 
ties have  been  exploited  effectively  to  minimize  IRIS  software  complexity. 

The  various  components  of  the  IRIS  data  base  have  been  assembled  and  struc- 
tured so  that  in  IRIS/IOC  there  is  a complete  model  of  records  for  all  the 
data  types  that  would  be  required  in  IRIS/FOC.  This  will  minimize  the 
effort  required  to  eventually  complete  this  data  base.  For  data  types  that 
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are  devoid  of  data  in  IRIS/IOC,  the  data  base  development  requirements  have 
specified  the  data  elements  precisely  enough  so  that  their  eventual  addition 
to  IRIS  will  require  a minimum  of  analytical  effort. 

The  analytical  capability  within  IRIS/ICjC  was  constrained  to  provide  minimal 
evaluation  results.  However,  the  capability  that  does  exist  could  be  in- 
creased by  simple  additions  to  the  existing  software.  It  is  anticipated 
that  as  user  familiarity  grows  he  will  recognize  the  needs  for  sophistica- 
tions that  would  assist  him  in  the  selection  of  candidate  information  systems. 
The  simplifications,  vis  a vis  what  conceivably  would  be  required  as  an 
ultimate  capability,  have  been  specifically  described.  The  manner  in  which 
IRIS/IOC  could  readily  assimilate  such  changes  has  also  been  described. 

The  scope  of  this  development  did  not  permit  the  optimization  of  the  man- 
machine  interface  in  IRIS.  This  part  of  the  IRIS/IOC  design  was  limited  to 
a functionally  usable,  albeit  non-optimum,  capability.  As  IRIS/IOC  is  used 
initially,  the  users  will  require  very  detailed  explanations  of  the  what  and 
why  of  the  directed  procedures.  The  periodic  assignment  of  new  personnel  to 
the  IPAC  Watch  team  will  continue  to  justify  the  more  detailed  attributes  of 
this  interface.  As  the  IRIS  users'  experience  with  IRIS  grows,  their  depen- 
dence on  IRIS  for  operating  guidance  will  decrease  accordingly.  This  vari- 
able level  user  direction  is  that  to  which  the  design  response  was  non- 
ootinial . 

Numerous  software  and  data  base  changes  that  would  enhance  the  operating 
efficiency  of  IRIS  became  apparent  during  the  pre-IOC  validation  of  the 
system.  In  addition  to  the  obvious  data  base  completion-related  additions, 
these  enhancements  include: 

o Enable  those  user  review  and  decision  functions  with  software,  when 
ADP  can  reliably  execute  those  functions, 
o Simplify  the  data  base  modification  so  that  they  can  be  reliably 
carried  out  by  the  routine  IRIS  user, 
o Modify  the  man-machine  interface  so  that,  at  the  least,  there  are 
sufficient  operational  short  cuts  to  enable  the  experienced  user 
to  execute  IRIS  rapidly. 

These  enhancements  are  discussed  in  detail  in  Section  IX  of  this  report. 
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Although  the  IRIS/IOC  utility  to  support  day-to-day  operations  is  limited  by 
its  current  data  base,  it  has  sufficient  power  to  serve  as  a tool  to  train 
users  and  to  enable  users  to  determine  which  of  the  identified  enhancements 
should  be  implemented  and  how  these  improvements  should  be  prioritized. 


SECTION  IX 


RECOMMENDATIONS 

A.  SYSTEM  ENHANCEMENTS 

During  the  last  half  of  the  system  development  and  the  pre-IOC  validation 
testing  of  IRIS,  the  potential  value  of  a number  of  software,  man-machine 
interface  and  data  base  enhancements  became  apparent.  During  the  actual 
design  of  IRIS,  these  system  refinements  were  not  anticipated,  principally 
because  the  system  was  not  being  "experienced";  only  specified.  The  per- 
muted number  of  intelligence  subjects,  information  need  categories,  collec- 
tion disciplines,  information  system  outputs,  intelligence  signatures, 
access  protocols,  and  information  system  technical /operational  characteris- 
tics, was  significantly  larger  than  the  specifications  for  any  one  of  these 
parameters  indicated.  Further,  the  effect  of  such  a large  volume  of  data 
(which  must  be  reviewed  relatively  quickly)  on  the  user's  ability  to  assimi- 
late information,  was  not  anticipated  unti  a complete  data  base  was  avail- 
able at  the  time  of  system  validation.  The  causes  of  these  phenomenologies , 
however,  are  not  limited  to  just  the  man-machine  interface  parts  of  IRIS. 
Operating  software  simplifications  and  data  base  deficiencies  and  simplifi- 
cations are  also  involved.  For  example,  an  ASCAP  record  that  does  not 
describe  the  output  comprehensively  enough,  can  result  in  a SYSMAT  that  over- 
qualifies the  information  system.  This  forces  the  IRIS  user  to  cope  with 
more  information  requirement  solutions  than  necessary.  Many  of  the  changes 
to  IRIS  that  would  reduce  any  current  awkwardness  in  carrying  the  user 
efficiently  to  his  information  solution  or  to  increase  the  utility  of  IRIS 

as  a general  intelligence-related  data  base  are  discussed  in  the  remainder 
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{ of  this  section.  Other  potential  enhancements  to  IRIS  are  included  in  the 

supplement  to  this  technical  report. 

1.  Information  Requirement  Input 

IRIS/IOC  requires  the  user  to  spend  time  and  effort  in  designating  subjects 
and  information  need  categories  to  model  his  information  requirement  for  the 
system.  The  simplification  (for  the  user),  and  the  increase  in  comprehen- 
sion (for  IRIS)  of  these  tasks,  compose  this  class  of  system  enhancements. 
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a.  Subject  Selection 


Subject  selection  by  IRIS  could  involve  the  user  indicating  what  he  thinks 
the  subject  of  his  requirement  is  (without  reference  to  the  detailed  IRIS 
concantenation)  followed  by  an  IRIS  search  of  a synonym  list;  the  elements 
of  which  are  correlated  with  the  SUCAT  (the  IRIS  subject  list)  identifica- 
tion numbers.  Failure  of  the  software  to  find  the  designated  subject  in 
the  resident  IRIS  synonym  set  would  result  in  the  user  being  prompted  to 
change  his  subject  word.  Such  initial  "failures"  in  the  subject  selection 
would  also  prompt  the  user  to  have  his  initial  designation  added  to  the 
synonym  list. 

b.  Information  Need  Correlation 

For  IRIS  to  correlate  the  information  needs  of  the  requirement  with  its  own 
set  of  information  need  categories  would  be  somewhat  more  involved.  IRIS 
could  be  charged  with  the  identification  of  key  words /phrases  in  the  desi- 
gnated information  requirement  prior  to  correlation  with  the  IRIS  informa- 
tion need  categories.  The  preparation  of  the  key  word /phrase  set  was 
actually  undertaken  informally  as  part  of  the  original  definition  of  the 
information  need  categories.  The  summary  of  different  classes  of  informa- 
tion needs  into  the  present  "categories"  is  seen  simply  as  the  inverse  of 
what  is  now  required  in  this  enhancement.  One  additional  complication, 
however,  would  involve  the  addition  of  certain  attributes  to  the  IRIS  subject 
list;  i.e.,  certain  state  or  action  qualities  do  not  apply  to  certain  sub- 
jects. With  the  subjects  so  identified,  this  IRIS  enhancement  would  only 
assign  valid  information  need  categories,  regardless  of  how  the  query  was 
posed. 

c.  Information  Requirement  Constraints 

Another  information  requirement  specification  enhancement  that  now  appears 
desirable  would  permit  the  user  to  limit  the  analysis  by  applying  constraints 
related  to  the  information  requirement  early  in  the  analysis  process.  An 
example  of  this  is  the  geographic  area  which  contains  the  subject  of  inter- 
est. IRIS/IOC  allows  the  user  to  consider  geographic  constraints  in  the 
acquisition  opportunity  evaluation.  This  can  only  be  done  after  he  has 
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reviewed  candidate  solutions.  Some  of  these  may  be  geographically  illogical. 
The  specification  of  a geographic  area  and  the  consequent  identification  of 
applicable  information  systems,  by  IRIS,  would  be  analogous  to  the  identifi- 
cation of  a subject  by  IRIS.  The  user  would  specify  the  geographic  area 
and  IRIS  would  search  a synonym  list  to  match  the  geographic  area  to  an  area 
number.  In  this  case,  however,  the  IRIS  country /geographic  area  list  would 
use  already  developed  and  proven  geographic  locators  as  the  basis  of  this 
synonym  set (analogous) to  those  used  in  the  PACOM  HUMINT  collection  require- 
ments system).  As  in  the  case  of  the  subject  synonym  list,  a failure  to 
match  would  be  reflected  in  a prompt  to  the  user  to  re-designate  an  area. 

The  use  of  this  identified  geographic  constraint  would  require  two  addi- 
tional IRIS  modifications.  The  IRIS/IOC  ASCAP  files  (see  Section  VI)  are 
based  on  unique  information  system  outputs.  Multiple  origin  locations  of 
these  outputs  are  discussed  within  the  record.  There  is  no  reason  why  such 
a single  ASCAP  record  cannot  be  expanded  into  a sequence  of  records  each 
differing  only  by  the  area/country  for  which  the  output  data  is  acquired. 
(More  mass  storage  would  be  required,  but  IRIS/IOC  uses  less  than  ten  per- 
cent of  that  which  is  available.)  Such  discreteness  in  the  ASCAP  structure 
would  permit  a corresponding  increase  in  the  specificity  in  the  related 
SYSMAT  data,  which  is  one  of  the  two  bases  of  the  information  requirement 
solution.  Inclusion  of  a country  or  geographic  area  code  in  the  SYSMAT 
would  be  accommodated  in  a manner  similar  to  that  presently  used  to  desig- 
nate Application  Categories  in  the  SYSMAT  analysis.  For  IRIS  to  use  this 
additional  data  would  be  a simple  extension  of  the  present  RIM  analysis. 
Currently,  IRIS  verifies  a match  between  Application  Categories  in  candidate 
SYSMATs  and  SUMATs  before  verifying  information  need  category  matches.  To 
verify  geographic  area  or  country  compatibility,  IRIS  would  merely  have  to 
match  the  identified  country  code(s)  with  those  indicated  in  the  candidate 
SYSMAT's. 

2.  On-Line  Editing 

Two  types  of  on-line  editing  are  presently  seen  to  be  desirable  added 
capabil it ies : 
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Permitting  the  user  to  "write"  on  the  IRIS  scratch  file  or  to  fill 
in  an  IRIS  formatted  message;  and 
o Exploitation  of  the  RSX-11D  (the  operating  system  used  by  the  IRIS 
computer)  Line  Text  Editor  in  conjunction  with  existing  IRIS  file 
build  software  to  facilitate  the  updating  of  IRIS  data  base  files. 

The  IRIS/IOC  scratch  file  is  slaved  to  data  displayed  routinely  to  the  user. 
This  denies  the  user  the  opportunity  to  make  "notes"  to  facilitate  his  ulti- 
mate decision  making.  This  software-related  change  would  permit  user  in- 
puts to  the  system.  Presently,  IRIS  displays  data  which  helps  the  user  to 
prepare  request  messages.  The  addition  of  an  edit  capability  would  permit 
the  user  to  prepare  these  messages  on  the  IRIS  terminal,  using  the  defined 
formats  in  the  MSGFORM  file. 

It  would  be  possible  to  integrate  the  existing  IRIS  file  build  software  and 
the  RSX-11D  Line  Text  Editor  so  that  the  file  update  and  correction  task 
will  be  simplified.  It  is  suggested  that  this  software  modification  would 
permit  the  modification  of  the  card  image  versions  of  the  IRIS  files  to  be 
followed  automatically  by  execution  of  the  file  build  programs. 

3.  Adaptation  to  Univac  1652  Terminal 

The  design  concepts  on  which  the  current  IRIS  are  based  were  established 
on  the  basis  of  the  output  data  being  presented  on  a dual-tube  display 
terminal,  the  Univac  1652.  This  terminal  was  originally  a part  of  the 
defined  IRIS  hardware  system.  Scheduling  problems  during  the  system  develop- 
ment forced  a mid-term  change  in  the  system  activation  plans  that  resulted 
in  IRIS/IOC  being  used  with  a single-tube  display.  Since  there  wasn't  time 
to  completely  redesign  IRIS  when  this  decision  was  made,  it  was  necessary 
to  require  the  user  of  IRIS/IOC  to  either:  remember  data  that  he  needs  for 

subsequent  steps  in  the  analysis  process,  or  to  continually  page  back  to 
prior  displays  to  retrieve  such  data.  The  dual  tube  presentation  would 
significantly  reduce  such  procedural  complications.  Additionally,  the 
Univac  1652,  in  its  function  as  a "smart"  terminal,  could  implement  IRIS 
commands  in  IRIS /IOC.  This  dual  tube  terminal  can  also  be  used  to  display 
information  graphically,  which  could  enhance  IRIS  information  presentation. 
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4.  Automation  of  User  Functions 

Presently,  the  IRIS  user  is  required  to  perform  manual  comparisons  between 
information  system  capabilities  and  that  which  would  be  needed  to  develop 
information  about  the  query  subje.cs.  The  user  is  also  required  to  input 
data  from  one  or  more  of  the  reference  files  into  the  acquisition  opportuni- 
ty analysis.  The  user  comparisons,  particularly  the  technical  validations 
of  the  information  system  candidates,  could  be  accomplished  via  software 
techniques.  The  INTSIG  (intelligence  signature)  files  are  structured  so 
that  a specified  subject  (of  an  information  query)  specified  to  the  system 
will  permit  only  the  applicable  signatures  (PHOTINT,  ELINT  or  RADINT)  to  be 
displayed  to  the  user.  These  signature  data  are  not  rigidly  formatted.  The 
related  technical  capability  of  the  information  system  being  evaluated  is 
also  stored  in  an  unformatted  manner.  However,  it  would  be  possible  to  re- 
structure both  of  these  data  ensembles  to  the  extent  necessary  to  permit  a 
comparison  via  software.  This  comparison  could  be  accomplished  as  a part  of 
the  query  interpretation  analysis.  In  IRIS/IOC,  the  user  can  eliminate  can- 
didate solutions,  but  only  after  he  has  involved  himself  in  a review  of  pre- 
sented information  system  outputs. 

IRIS/IOC  requires  the  user,  during  the  review  of  the  candidate  information 
systems,  to  note  certain  data  which  is  required  as  input  to  the  subsequent 
acquisition  opportunity  analyses.  Such  data  could  be  more  efficiently 
accumulated  in  a separate  array  in  which  its  location  and  identity  are  de- 
fined. Then,  when  an  acquisition  opportunity  analysis  is  directed  by  the 
user,  this  data  would  be  carried  over  automatically. 

5.  Casual  Review  of  IRIS  File  Review 

IRIS/IOC  has  a primary  mission  of  supporting  the  solution  of  information 
requirements  or  queries  by  facilitating  the  selection  of  candidate  system 
outputs  which  could  contribute  to  these  solutions.  This  process  involves 
the  use  of  various  data  files,  the  content  of  which  could  be  of  use  to  non- 
typical IRIS  users.  In  order  that  such  use  be  made  of  these  files,  two 
software  modifications  would  be  effective  aids. 
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a.  Simple  File  Review 

A simple  file  review  (without  any  edit  capability)  would  be  one  of  these 
modifications.  This  could  involve  only  a file  call-up  and  the  use  of  the 
existing  paging  and  printing  commands.  This  would  be  particularly  useful 
for  analyst  review  of  various  ASCAP  data,  either  for  the  purpose  of  review- 
ing the  quality  of  such  data  or  for  extracting  data  applicable  to  an  analy- 
sis problem. 

b.  Specialized  Search  Criteria 

An  extension  of  the  above  file  review,  also  tailored  to  the  use  of  IRIS  by 
analysts  who  have  an  interest  only  in  specific  files,  would  enable  queries, 
characterized  by  recognized  search  criteria,  to  be  answered.  The  ASCAP 
data  is  the  focus  on  this  recommendation.  As  presently  structured,  IRIS 
ASCAP  records  are  free-form  text  records  and  thus,  do  not  lend  themselves 
readily  to  ADP  queries.  However,  each  of  these  records  is  prefaced  by  an 
executive  summary  which  could  be  restructured  in  a manner  that  would  support 
this  proposed  modification.  An  alternate  approach  would  involve  the  crea- 
tion of  a code  set  invisible  to  the  user  but  associated  with  each  ASCAP 
record.  In  this  code  set,  certain  key  attributes  of  the  information  system 
t-  or  the  output  for  which  the  ASCAP  record  exists  would  be  identified.  This 

code  set  would  be  analogous  to  the  set  of  pointers  associated  with  the  SYSCAT 
and  used  to  present  a potential  solution  to  an  information  requirement  to 
the  IRIS  user.  These  pointers  identify  applicable  file  records  which  are 
■ associated  with  the  identified  output  and  enable  IRIS/IOC  software  to  know 

where  it  has  to  go  when  certain  commands  are  executed.  In  the  case  of  this 
proposed  enhancement,  these  transparent  identifiers  could  indicate:  type  of 

information  system,  a range  in  which  the  output  timeliness  falls,  a time 
T span  in  which  the  output  accuracy  or  uncertainty  falls,  owner /operator , 

frequency  of  reporting,  etc.  Such  a set  of  screening  parameters  would  be 
convenient  but  inflexible  if  other  system  or  output  parameters  were  speci- 
fied. The  advantage,  of  course,  is  that  the  existing  records  would  not  have 
to  be  forced  into  a format  that  would  complicate  subsequent  data  base  main- 
tenance. 
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6.  Dialogue  Modifications 


The  man-machine  interface  in  IRIS  was  developed  on  a purely  functional 
basis.  This  involved  the  determination  of  what  the  user  had  to  do  to  enable 
progression  to  subsequent  IRIS  analysis  phases,  and  the  translation  of  these 
tasks  into  instructions  to  the  user.  This  interface  was  not  optimized.  It 
is  proposed  that  optimization  could  be  achieved  by  the  use  of  a dialogue 
synthesizer,  such  as  has  been  developed  by  the  Martin  Marietta  Man  Computer 
Interface  Laboratory. 

7.  Remote  or  Multiple  Terminals 

Two  possible  enhancements  are  recognized:  namely,  multiple  terminals  hard 

wired  to  the  IRIS  computer  and,  modification  of  IRIS  software  so  that  the 
IRIS  computer  can  become  an  IDHS-C  node. 


RSX-11D,  the  operating  system  on  the  IRIS  computer,  has  the  inherent  capa- 
bility to  support  multiple  users,  providing  certain  accessing  protocols  are 
incorporated  into  IRIS  software.  This  is  a well-defined  procedure  but  was 
not  executed  in  the  building  of  IRIS /IOC. 


For  IRIS  to  serve  as  an  IDHS-C  node,  software  changes  would  be  required. 

For  instance,  modifying  the  FICPAC  switch  so  that  it  recognizes  the  IRIS 
computer  and,  modifying  IRIS  software  so  that  it  could  readily  validate  the 
clearance  of  users  at  remote  IDHS-C  nodes  relative  to  their  right  to  access 
IRIS  data. 

B.  OTHER  SYSTEM  APPLICATIONS 

1.  Technical  Intelligence 

Although  IRIS/IOC  is  intended  to  be  used  to  support  the  resolution  of  cur- 
rent intelligence  information  requirements,  its  analysis  structure  (i.e., 
the  development  of  candidate  solutions  to  posed  queries  and  the  presentation 
of  various  data  which  provide  in  depth  discussion/understanding  of  these 
possible  solutions)  could  support  the  technical  intelligence  analyst.  The 
frame  of  reference  in  which  such  an  analyst  would  use  an  IRIS-type  tool, 
however,  would  not  have  the  objective  of  initiating  data  acquisition  or 
influencing  processing.  Rather,  this  use  would  be  concerned  with  the 
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identification  of  sources  of  data  that  may  not  be  routinely  available,  or, 
of  collateral  data  source*  which  may  complement  the  more  routine  inputs  to 
his  analysis.  To  use  the  IRIS  query  interpretation  process,  the  subject 
list  would  have  to  be  more  discrete.  Those  subject  categories  that  are 
encountered  only  in  operational  or  political  scenarios  would  be  eliminated. 
The  information  need  categories  would  also  require  revision  to  reflect  more 
specifically  what  is  characteristic  of  a technical  intelligence  query.  Many 
of  the  current  IRIS  information  system  outputs  have  no  technical  intelligence 
value.  These  would  be  eliminated.  Sources  ignored  in  IRIS/IOC,  because 
their  typical  technically  oriented  product  has  little  or  no  value  to  an 
operational  intelligence  consumer,  would  replace  some  of  the  present  infor- 
mation system  data.  Consequently,  the  present  IRIS  SUMATs  and  SYSMATs  would 
have  to  be  re-created.  The  consequent  solutions  to  posed  queries  would 
identify,  generally,  different  outputs  than  are  now  presented.  There  would 
continue  to  be  a need  for  the  subject  intelligence  signature  analysis,  but 
the  collection  opportunity  analysis  and  the  message  preparation  parts  of 
IRIS  would  not  be  required. 

Experienced  analysts  may  not  be  the  users  of  this  adaptation  of  IRIS.  It 
would,  however,  be  a useful  tool  for  training,  or  for  use  by  analysts  whose 
experience  with  intelligence  products  is  limited  to  a single  collection  dis- 
cipl ine. 

2.  General  Applications 

The  requirements  interpretation  analysis  is  not  limited  to  intelligence  pro- 
blems. It  is  a technique  that  can  be  effectively  used  in  any  environment 
in  which  there  is  a need  to  develop  answers  to  questions  on  a variety  of 
subjects  in  a short  period  of  time.  Further,  when  the  answers  to  such 
questions  cculd  potentially  be  imbedded  in  a relatively  large  number  of 
sources  (large  compared  to  the  number  of  sources  with  which  a single  indi- 
vidual or  a small  group  of  individuals  could  be  intimately  familiar)  then 
the  likelihood  is  small  that  the  query  will  be  posed  by  an  individual  who 
can  infer  an  optimum  solution  without  extensive  help  or  delays.  In  such  an 
environment,  the  IRIS  requirement  interpretation  process  represents  a struc- 
tured approach  to  identification  of  information  sources  which,  in  turn,  can 
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be  briefly  described  so  that  the  questioner  can  rapidly  perform  in  a priori 
evaluation  of  the  potential  source. 


3.  General  Screening  Processes 

The  RIM  analysis  screening  process  could  be  applied  to  the  screening  of 
other  types  of  data;  e.g.,  libraries,  personnel  expertise,  other  assets, 
etc.,  to  determine  candidate  solutions  to  various  problems. 


METRIC  SYSTEM 


BASE  UNITS: 

Quantity 


Unit 


SI  Symbol 


length 

mass 

time 

electric  current 
thermodynamic  temperature 
amount  of  substance 
luminous  intensity 

SUPPLEMENTARY  UNITS: 

plane  angle 
solid  angle 

DERIVED  UNITS: 

Acceleration 

activity  (of  a radioactive  source) 

angular  acceleration 

angular  velocity 

area 

density 

electric  capacitance 

electrical  conductance 

electric  field  strength 

electric  inductance 

electric  potential  difference 

electric  resistance 

electromotive  force 

energy 

entropy 

force 

frequency 

illuminance 

luminance 

luminous  flux 

magnetic  field  strength 

magnetic  flux 

magnetic  flux  density 

magnetomotive  force 

power 

pressure 

quantity  of  electricity 
quantity  of  heat 
radiant  intensity 
specific  heat 
stress 

thermal  • undue  tivily 
velocity 

viscosity,  dynamic 

viscosity  kinematic 

voltage 

volume 

wavenumber 

work 


metre 

kilogram 

second 

ampere 

kelvin 

mole 

candela 


radian 

steradian 


metre  per  second  squared 

disintegration  per  second 

radian  per  second  squared 

radian  per  second 

square  metre 

kilogram  per  cubic  metre 

farad 

siemens 

volt  per  metre 

henry- 

volt 

ohm 

volt 

joule 

loule  per  kelvin 

newton 

hertz 

lux 

candela  per  square  metre 
lumen 

ampere  per  metre 

weber 

tesla 

ampere 

watt 

pascal 

coulomb 

joule 

watt  per  steradian 

loule  per  kilogram-kelvin 

pascal 

watt  per  metre-kelvin 
metre  per  second 
pascal-second 
square  metre  per  second 
volt 

cubic  metre 
reciprocal  metre 
loule 


m 

s 

A 

K 

mol 

cd 


rad 

sr 


r 

s 

II 

V 


V 

I 

N 

Hz 

lx 

Im 

Wb 

T 

A 

VV 

Ha 

C 

I 


I 


SI  PREFIXES: 


Multiple  ation  Eai  lois 


I'rnfix 


1 000  000  000  000 

3! 

10” 

llTH 

1 000  000  000 

= 

HI- 

K>K* 

1 000  000 

= 

10* 

moga 

1 000 

3 

10’ 

kilo 

100 

3 

10’ 

hnclo* 

10 

3 

10' 

(lnk«* 

0 1 

3 

10-' 

dm:i* 

0.01 

= 

10-’ 

c:c?nti  * 

0 001 

= 

10-' 

m ill  i 

0 000  001 

* 

10'  * 

micro 

0.000  000  001 

- 

10-* 

nano 

0.000  000  000  007 

a 

10-  ” 

pico 

0.000  000  000  000  001 

a 

10- ” 

fnmto 

0.000  000  000  000  000  001 

= 

10-" 

alio 

* To  be  avoided  where  possible 


Formula 


m/s 

(disintegration)^ 

rads 

rads 

m 

kg  m 

A-s/V 

AV 

V'm 

Vs  A 

W'A 

ViA 

W'A 

N-m 

|/k 

kg-nvs 

(cycle)is 

I m/m 

cd/m 

cd-sr 

A/m 

Vs 

Wb/m 

I* 

N/m 

A-s 

N-m 

W sr 

|/kg*K 

N'm 

Wink 

mis 

Pa-s 

ms 

W'A 

m 

(wave|/m 

N-m 


SI  Symbol 

T 

i; 

M 

k 

h 

da 

d 


m 

M 

n 

P 

f 


a 


2 


